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Additional Transition Functionality for IPv6 
Abstract 


This document proposes an additional mechanism intended to both 
facilitate transition from IPv4 to IPv6 and improve the latter’s 
security and privacy. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This is a contribution to the RFC Series, independently of any other 
RFC stream. The RFC Editor has chosen to publish this document at 
its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8136. 


Copyright Notice 


Copyright (c) 2017 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. 
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1. Introduction 


In a recent statement [IABv6], the Internet Architecture Board deemed 
that the Internet Engineering Task Force is expected to "stop 
requiring IPv4 compatibility in new or extended protocols" and that 
future work will "optimize for and depend on IPv6é". In the interest 
of promoting these goals, this memo makes an important change to IPv4 
node requirements [RFC1122] and adds a missing security feature to 
IPv6 [RFC2460]. 


1.1. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are not to be interpreted as described in 
[RFC2119]. 


2. Required Function of All IPv4 Nodes 


To ensure that all routers, firewalls, load balancers, and other 
forms of middleboxes can readily identify IPv4 packets and deal with 
them appropriately (selective dropping, switching to the slow path 
through a router, sending them to the longest path first, etc.), all 
IPv4 nodes MUST set the security flag defined by [RFC3514] to 1. 
This should be sufficient to ensure that implementers of dual stack 
applications prefer IPv6é when given the choice, and that the Happy 
Eyeballs algorithm [RFC6555] will usually favour the IPv6 path. 
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Security Flag for IPv6 Packets 


The above requirement will somewhat nullify the practical effect of 
the IPv4 security flag for benign traffic, but this disadvantage can 
readily be overcome by adding an equivalent flag for IPv6; in fact, 
this is highly desirable to maintain feature equivalence between IPv4 
and IPv6. Fortunately, this can easily be achieved since IPv6 
supplies so many bits. The solution defined here is that the 
Security Flag bit for an IPv6 packet is simply the parity of the 
source address of the packet. In other words, if the source address 
contains an odd number of 1s, the flag is True; otherwise, it’s 
False. All other considerations for the flag are exactly as 
described in [RFC3514]. 


For an interface whose IPv6 address is set by Stateless Address 
Autoconfiguration [RFC4862], it is the host itself that determines 
the state of its security flag, by choosing an appropriate Interface 
Identifier value. Fortunately this is now possible and compatible 
with [RFC7136], [RFC7217], [RFC7421], and [RFC7721]. 


For an interface whose IPv6 address is set by DHCPv6 [RFC3315] or 
manually, the network administrator is free to choose an Interface 
Identifier that provides the desired security flag that is also 
compatible with [RFC7721]. 


An exception case is a link with a 127-bit prefix [RFC6164]. Since 
there is only one bit available as an Interface Identifier, one end 
or the other will inevitably have its security flag set, and the 
other won’t. In this case, the node at one end will simply interpret 
the other end’s security flag to mean the opposite of what it says, 
and vice versa. 


Since RFC 6164 is designed for links between routers, in the case 
where different ISPs are at each end of the link, it is normal 
operational practice for one ISP to consider the other ISP to be 
evil. 
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4. Advanced Solution 


In the event that the previous solution proves too simple to deploy 
in practice, a more advanced solution is also defined. It uses a new 
IPv6 hop-by-hop User Security Flag Option (UFO). 


The UFO is a hop-by-hop option that can be included in any IPv6 
packet. Multiple UFOs MUST NOT be present in the packet. The UFO 
has no alignment requirement. Its format is as follows: 


0 t 2 3 
Oo 234 5e Tg GON CTS By BP 435 6: Tg OY OTe 2e 35-45: e T 28-90) L 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Option Type | Option Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++HH+++HHHHHHHHHHHH H 
UserSecFlag | 
+-+-+-+-+-+-+-+-+ 


User Security Flag Option Layout 
Option Type 


8-bit identifier of the type of option. The option identifier 
for the User Security Flag Option (0x7g) has not been allocated 
by the IANA. 


Option Length 


8-bit unsigned integer. The length of the option (excluding the 
Option Type and Option Length fields). The value MUST be 1. 


UserSecFlag 


8-bit unsigned integer. Bit 0 has the functionality defined in 
[RFC3514]. The other bits are reserved and MUST be zero or one. 


4.1. Privacy Extension 


The mechanism can be extended to add a privacy flag. With the 
mechanism of Section 3, the privacy flag could be encoded by using 
quaternary parity (CRC-2) to obtain an extra bit. However, this 
would waste considerable amounts of address space and SHOULD NOT be 
done. With the UFO mechanism, bit 1 of UserSecFlag is defined as the 
privacy flag. If set, it means that the packet contains private 
information and MUST NOT be inspected en route. All firewalls, 
monitoring devices, and government agencies MUST respect this rule. 
This option is expected to be much more computationally efficient 
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than conventional privacy techniques like IPsec and Transport Layer 
Security (TLS) as no encryption or key management is required to 
achieve the desired privacy. 


5. Security Considerations 


The security considerations of [RFC3514] now apply to IPv6. However, 
with the security flag being set for all IPv4 packets, there is a 
risk that all IPv4 traffic will now be treated as a very distributed 
denial-of-service attack. 


Given the recent experience with very large scale DDoS attacks from 
Internet of Things (IoT) devices like IP Cameras, phishing attacks, 
malware, etc., that occur on the IPv4 Internet, it is a safe 
assumption that all IPv4 packets are evil. 


Since the mechanism described in Section 3 is compatible with 
[RFC7721], address privacy is not impacted. Also, with that 
mechanism, exactly half the IPv6 address space will indicate that the 
security flag is set, so we can assert that the IPv6 Internet is only 
half evil. 


6. IANA Considerations 
This document does not require any IANA actions. 
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